The DBMS must automatically disable accounts after a 35-day period of account inactivity.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-61563	O121-C2-002100	SV-76053r1_rule		Medium

Description
Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application-related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Applications need to track user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle. Database accounts must be disabled by the DBMS, the OS, or an enterprise-level authentication/access mechanism after 35 days of inactivity in order to mitigate the risk of unauthorized access. Unauthorized access is particularly difficult to detect on unused accounts due to the lack of user oversight.

Description

Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application-related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Applications need to track user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle. Database accounts must be disabled by the DBMS, the OS, or an enterprise-level authentication/access mechanism after 35 days of inactivity in order to mitigate the risk of unauthorized access. Unauthorized access is particularly difficult to detect on unused accounts due to the lack of user oversight.

STIG	Date
Oracle Database 12c Security Technical Implementation Guide	2015-12-21

Details

Check Text ( C-62435r1_chk )
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding. For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, determine whether an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed. If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding. - - - - - Check to see what profile a user is associated with, if any, with this query: SQL> select username, profile from dba_users where username = ''; Then check the profile to see what the password_life_time is set to in the table dba_profiles; the password_life_time is a value stored in the column named resource_name. SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper() = 'PASSWORD_LIFE_TIME'; - - - - - The following are notes on a method suggested by Oracle. In SRG-APP-000075-DB-000029 - The DBMS must, upon successful logon, display to the user the date and time of the user's last logon advocated using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.logon_audit_info_all and trap logon information with a logon trigger. Check for the existence of the sys.logon_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue. $ sqlplus connect as sysdba SQL> select count(*) from SYS.logon_AUDIT_INFO_ALL; If the count is greater than zero, then the table exists and data is being inserted.

Check Text ( C-62435r1_chk )

If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.

For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, determine whether an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed.

If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding.

- - - - -
Check to see what profile a user is associated with, if any, with this query:
SQL> select username, profile
from dba_users
where username = '';

Then check the profile to see what the password_life_time is set to in the table dba_profiles; the password_life_time is a value stored in the column named resource_name.

SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper() = 'PASSWORD_LIFE_TIME';

- - - - -
The following are notes on a method suggested by Oracle.

In SRG-APP-000075-DB-000029 - The DBMS must, upon successful logon, display to the user the date and time of the user's last logon advocated using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.logon_audit_info_all and trap logon information with a logon trigger.

Check for the existence of the sys.logon_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue.

$ sqlplus connect as sysdba
SQL> select count(*) from SYS.logon_AUDIT_INFO_ALL;

If the count is greater than zero, then the table exists and data is being inserted.

Fix Text (F-67479r1_fix)
For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement: ALTER PROFILE ORA_STIG_PROFILE LIMIT PASSWORD_LIFE_TIME 35; (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples. ORA_STIG_PROFILE is available in DBA_PROFILES, starting with Oracle 12.1.0.2.) If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days.

Fix Text (F-67479r1_fix)

For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement:
ALTER PROFILE ORA_STIG_PROFILE LIMIT PASSWORD_LIFE_TIME 35;
(See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples. ORA_STIG_PROFILE is available in DBA_PROFILES, starting with Oracle 12.1.0.2.)

If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days.